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(54) Abstract Title 

Three party cryptosystem having pairs of private keys 



(57) Users (A, B) of a cryptosystem send and receive messages with the help of a trusted third party (TTP) 
using private keys (X) and public keys (P) which encapsulate said private keys. Each user (A, B) holds a private 
key (X A1 , X B1 ) and the third party is entrusted with a corresponding private key (X A2 , X B2 ) for each user. The 
trusted third party responds to a challenge (CHA) from a user by issuing a response (RES) which encapsulates 
the corresponding private key <X A2 , X B2 ) so that the user can use the response in combination with the private 

key (X A1 , X B1 ) it already holds to decrypt or sign a message. The response takes the form r 2 HXBl mod p, 
where r is a private parameter, p is a public system parameter *(eg. a large prime) and H is an exponent 
function (eg. a one-way, collision-resistance hash function). The message (e) is then decrypted to obtain the 

original message (m) via m « e (ii HX »« RES)* 1 mod p. 

This system removes the need for key escrow or Public Key Infrastructure (PKI) since the trusted third 
party is required to know only a private key corresponding to the private key of each user, rather than the 
user's private key itself. 
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CRYPTOSYSTEM 

This invention relates to cryptosystems and methods for encrypting/decrypting and signing 
messages. 

In 1976 Diffie and Hellman introduced the public key exchange that is based on the Diffie 
Hellman Problem (DHP) that is closely related to the well known Discrete Logarithm 
Problem (DLP). The intractability of DLP is equivalent to the security of the ElGamal 
public key scheme. The RSA public key cryptosystem was introduced in 1978, and may be 
used for both secrecy and digital signatures. The RSA cryptosystem works in Zn, where n 
is the product of two large primes p and q, and its security is based on the difficulty of 
factoring n, that is, the integer factorization problem. Since then, various ElGamal and 
RSA type cryptosystems have been proposed to enhance existing defences against "chosen 
ciphertext attacks". 

In 1984 Shamir proposed identity-based cryptosystems and signature schemes that enable 
simple key management in email systems. For example, when Alice sends an email to Bob 
at bob@cipherdoctor.com, she simply encrypts her message using the public key string 
bob@cipherdoctor.com. There is no need for Alice to obtain Bob's public key certificate. 
When Bob receives the encrypted email he contacts a Trusted Third Party (TTP). Bob 
authenticates himself to the TTP and obtains his private key from the TTP. Bob can then 
read his email. This system does not require a Public Key Infrastructure (PKI) so Alice can 
send encrypted email to Bob even if Bob has not set up his public key certificate. 
However, this system employs key escrow since the TTP knows Bob's private key. 

An object of the invention is to provide an improved cryptosystem which has equivalent 
functionality to ID based public key cryptosystems, but which avoids the need for key 
escrow/PKI. 

The invention consists in a cryptosystem in which users send and receive messages with 
the help of a trusted third party for security purposes making use of private keys and public 
parameters which encapsulate said private keys, each user holding a private key and the 
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trusted third party being entrusted with a corresponding private key for each user, and the 
trusted third party being adapted so that it is responsive to a challenge from a user by 
issuing a response which encapsulates the corresponding private key so that the user can 
use the response in combination with the private key already held by the user to decrypt or 
sign a message. 

When the cryptosystem operates to encrypt/decrypt a message, the transmitting user 
encrypts the message to a recipient user using the public parameters which encapsulate the 
private keys of the recipient user. One of these private keys is held by the recipient user, 
but the other is held by the trusted third party, and thus the recipient user issues a challenge 
to the trusted third party so as to obtain a response in which the other private key is 
encapsulated. The private key held by the trusted third party is therefore kept secret, but it 
can be accessed by the recipient in its encapsulated form and used to decrypt the message. 

Preferably, the encryption process also makes use of private parameters generated by the 
transmitting user, and these are transmitted to the recipient user for use in the challenge and 
response so that the decryption process is suitably enabled. These private parameters, as 
well as increasing encryption security, also serve to encapsulate the private key in the 
response. 

When the cryptosystem operates to sign a message, the transmitting user creates a 
multi-part signature which is transmitted with the message so that a recipient user can 
check the signature against the signed message. The signature comprises one part 
generated directly by the transmitting user so as to encapsulate the private key held by the 
transmitting user, and another part encapsulating the response from the trusted third party 
following a challenge by the transmitting user, so that it incorporates the private key of the 
transmitting user held in trust by the trusted third party. 

Preferably, the signature also includes a private parameter generated by the transmitting 
user which is used in generating the other two parts of the signature and which is 
transmitted with said other two parts to the recipient user for checking the signed message. 
This serves to increase signature security. 
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The challenge preferably makes use of the ID of the user issuing the challenge, and this ID 
is also incorporated in the encryption process or signing process. However, it is a feature 
of the invention that, although the encryption and signing processes involve private keys, 
the challenge does not use a private key and thus the private keys held by users are kept 
secret from the trusted third party. 

The invention will now be described by way of example with reference to encryption and 
decryption of a message, and signing a message. 

A trusted third party or key center TTP is established and publishes the public system 
parameters required by users of the cryptosystem to encrypt and sign messages. The 
cryptosystem is based on the Diffie-Hellman scheme over multiplicative group Zp, which 
is cyclic. The public system parameters consist of: 

p - a large prime, 

q - a large prime divisor of p - 1 , 

g! and g 2 - integers of order q where (1 <gi, g2 <q)> 

h - a one-way collision-resistance hash-function. 

Also, each user has two private keys JST, one being held by and being secret to the user, and 
the other being held by and being secret to the TTP. For example, a typical user Alice has 
a private key X Al , and the TTP holds a corresponding private X A2 , where (1 <X Au Xa 2 <q); 
and a typical user Bob has a private key X B%9 and the TTP holds a corresponding private 
key X Ai , where (1 <X Bu Xb 2 <q). 

Based on these private keys X M X A ^ X Bu X Bl corresponding public parameters P are 
published as follows: 

Pa, =£,^ l mod/7 
Pa 2 =gi* A2 modp 
P'b, =g\ X ** modp 
Pb 2 =g 2 X * 2 modp 
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Thus the public system parameters consist of p, q, h, g b g 2 , Pi u Pi 2 , where i = A, B, 1. 

In order to encrypt a message m e Zp, a user, such as Alice who wants to send a message to 
Bob, randomly chooses two integers ki and k 2 , where 1 <k,, k 2 <q, and computes the 
following: 

n = g { kl mod p t 
n =gi l mod p 9 
and H = h(n,r 2 ID), 

where ID is the binary string for the email address of Bob, for example, 
bob@cipherdoctor.com. The encrypted message e is then generated as follows: 

e = mP% l P%* mod p. 

Alice sends the encrypted message e and the parameters n and r 2 to Bob. 

In order to decrypt the encrypted message e, Bob first computes CHA = (n, r 2 , ID) and 
sends this as a challenge to TTP. TTP then computes H = h(CHA) = h(n, r 2 , ID) and sends 
Bob a response RES ~ r 2 1 mod p. 

Bob then uses the response RES together with his private key X Bx to decrypt the message 
as follows: 

m=e(r" X8] RES)- { mod p. 

It can be shown by simple substitution that this decryption formulation for m is the inverse 
function of the encryption formulation of e quoted above, and thus decryption is effective. 

In order to sign a message m g Zp, Alice randomly chooses two integers ki and k 2 , where 
1 <ki, k 2 <q, and computes the following: 
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r = mg\ l g k 2 2 mod p 9 
H=h(r 9 m 9 ID) 9 
and s\ = k\ -HX A] mod q. 

Alice then computes CHA = (r, ra, ID) and sends this as a challenge to TTP. 

TTP then computes H = h(CHA) and sends Alice a response RES = g 2 ^ 2 • 

Alice then computes 

S2 = g2 2 RES mod q = HXai mod q. 

Alice then sends Bob a signature message Sig(m) = (r, st, S2) which Bob can use to verify 
the message m by substitution in the formulation: 

r = mg\ x s 2 P% x P H A2 mo& p. 

Thus if the signatory follows the above signature protocol, the recipient can be certain as to 
the true identity of the signatory. 

In order to add message recovery to a digital signature scheme, a public redundancy 
function R and its inverse R" 1 are introduced, the selection of R being critical to the security 
of the system. 

To sign a message m e Zp, Alice randomly chooses two integers ki and k 2 , where 
1 <ki, k 2 <q, and computes the following: 

m = R(m), 
r = m'g] kl g2 k2 mod p 9 
H=h(rJD% 
and s\ = k\ -HX Ax mod q. 
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Alice then computes a challenge CHA = (r, ID) and sends it to TTP. TTP then computes 
H = h(CHA) and sends the response RES = g^'to Alice. Alice then computes: 

s 2 =g k 2 2 RES mod q = g^"*" 2 mod q. 

Alice then sends the signature message Sig(m) = (r, s,, s 2 ) to Bob. After receiving Sig(m), 
the message is verified by Bob using the formulation: 

m' =r&szP H Ax P H Al mod p. 
After checking the validity of m', the message is recovered by computing 
m = /r>(m')- 

Whilst the invention has been described above with reference to a cryptosystem having just 
one trusted third party TTP, it will be appreciated that two or more TTPs may be provided, 
each being entrusted with a corresponding unique private key X a „ for each user, so that a 
user is required to perform a challenge and response routine with each TTP before the user 
has all of the encapsulated private keys required for decrypting or signing a message. 

Also, whilst the pairs of public parameters P A ,, Pa, and P Bl , Pb 2 involve system 
parameters g, and g 2 , which take different values, g, and g 2 could be set at the same value 
to simplify the system. Also, where there are two or more TTPs, the values of two or more 
of the system parameters gi, g 2 , ... gn could be the same. 

The security of the proposed scheme is based on the security of Diffie-Hellman problem 
and one-way collision resistance hash-functions. Given the fact that there is no known 
method for "breaking" DHP or for finding collisions on one-way collision-resistance 
hash-functions, it is computationally infeasible to break the proposed scheme. 

It will be appreciated that the use of two or more private keys per user, one held by the user 
and one by each TTP, and the challenge and response technique with each TTP, enables a 
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computationally secure cryptosystem to be set up without embedding key escrow and 
without any PKI requirement so all users enjoy secure communication with each other 
without possessing verified certificates. The invention therefore provides an implicitly 
authenticated public key cryptosystem which avoids disclosing user's private keys even to 
the TTP. 
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CLAIMS 



1 A cryptosystem in which users (A, B) send and receive messages (m) with the help 
of a trusted third party (TTP) for security purposes making use of private keys (AO and 
public parameters (P) which encapsulate said private keys (X), each user (A, B) holding a 
private key (X A] X Bl ) and the trusted third party (TTP) being entrusted with a 
corresponding private key (X Al ,X Bl ) for each user (A, B), and the trusted third party (TTP) 
being adapted so that it is responsive to a challenge (CHA) from a user (A, B) by issuing a 
response (RES) which encapsulates the conesponding private key (X A ,X Bl ) so that the 
user (A, B) can use the response (RES) in combination with the private key (X Al ,X B ,) 
already held by the user (A, B) to decrypt or sign a message. 

2. A cryptosystem as claimed in claim 1 in which users (A, B) generate private 
parameters (r; r,, r 2 ) which encapsulate user parameter selections (k,, k 2 ) and which are 
incorporated in the challenge (CHA) and response (RES). 

3. A cryptosystem as claimed in claim 2 in which a transmitting user (A) encrypts a 
message (m) to a recipient user (B) using the public parameters (P Bu Pb 2 ) which 
encapsulate the private keys {X Bu X„ 2 ) of that recipient user (B), and private parameters (r,, 
r 2 ) generated by the transmitting user (A), the private parameters (r,, r 2 ) being transmitted to 
the recipient user (B) to decrypt the encrypted message (e). 

4. A cryptosystem as claimed in claim 3 in which the transmitting user (A) selects 
integers (k,, k 2 ) and uses each in a public generator function to generate a respective private 
parameter (n, r 2 ). 

5. A cryptosystem as claimed in claim 4 in which the message (m) is encrypted 
according to the general formulation 

mP Bl Hk] P Bl Hia modp, 

where H is an exponent function that incorporates the private parameters (r,. r 2 ) and p is a 
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public system parameter in the form of a large prime integer. 

6. A cryptosystem as claimed in claim 5 in which the public generator function for the 
private parameters (r b r 2 ) takes the form 

ri = gi u mod p 
and r 2 = g2 k2 mod p, 

and in which Pb 2 = g\ 1 mod P 
and Pb 2 =g 2 ^ 2 niodp, 

where gi and g2 are public system parameters. 

7. A cryptosystem as claimed in claim 6 in which g! = g2. 

8. A cryptosystem as claimed in any one of claims 5 to 7 in which the exponent 
function H incorporates the identity (ID) of the transmitting user (A). 

9. A cryptosystem as claimed in any one of claims 5 to 8 in which the exponent 
function H comprises a one-way, collision-resistance hash function (h). 

10. A cryptosystem as claimed in any one of claims 5 to 8 in which the response RES 
takes the general form 

hx B2 
r 2 mod p. 

11. A cryptosystem as claimed in claim 10 in which the recipient user (B) decrypts the 
encrypted message (e) to recover the original message (m) using the formulation 

m = e(r } HXBl RES)' l modp. 

12. A cryptosystem as claimed in any one of the preceding claims in which the 
challenge (CHA) incorporates the identity (ID) of the recipient user (B). 
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13. A cryptosystem as claimed in claim 2 in which a transmitting user (A) signs a 

message (m) by creating a multi-part signature message Sig(m) which is transmitted with 
the message (m) so that a recipient user (B) can check the signature message Sig(m) against 
the message (m), the signature message comprising one part (si) generated directly by the 
user (A) so as to encapsulate the user's private key (X A} \ and another part (s 2 ) 
encapsulating the response (RES) from the trusted third party (TTP). 

14. A cryptosystem as claimed in claim 13 in which the multi-part signature message 
Sig(m) includes the private parameter (r). 

15. A cryptosystem as claimed in claim 14 in which the private parameter (r) is 
generated by a public generator function that takes the general form 

r = mg\ l gi kl mod/? 
where gi, gi and p are public system parameters and p is a large prime integer. 

16. A cryptosystem as claimed in claim 15 in \yhich gi = g2. 

17. A cryptosystem as claimed in any one of claims 13 to 16 in which the challenge 
(CHA) incorporates the private parameter (r), the identity (ID) of the transmitting user (A) 
and the message (m). 

18. A cryptosystem as claimed in claim 14 or 16 in which the response (RES) takes the 
form 

where H is an exponent function that incorporates the private parameter (r), the identity 
(ID) of the transmitting user (A) and the message (m). 
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19. A cryptosystem as claimed in claim 18 in which the exponent function H is a 
one-way, collision-resistance hash function (h). 



20. A cryptosystem as claimed in any one of claims 13 to 19 in which the parts (si, s 2 ) 
of the signature message Sig(m) take the general form 

s\ =k{ -HXa x mod q 
and s 2 = g 2 ~ k2 RES mod q 

where q is a public system parameter in the form of a large prime division of p-1 . 

21. A cryptosystem as claimed in any one of the preceding claims which involves two 
or more trusted third parties (TTP), each of which is entrusted with a corresponding private 
key (X a2 ,Xb 2 - X ai ,X b >) for each user (A, B), each being adapted to respond to a challenge 
(CHA) from a user (A, B) by issuing a response (RES) which encapsulates the 
corresponding private key (X a2> X bl - X a2i X b ^\ 

22. A cryptosystem as claimed in claim 7 or 16 which involves two or more trusted 
third parties (TTP), each of which is entrusted with a corresponding private key (X) for 
each user (A, B)> each being adapted to respond to a challenge (CHA) from a user (A, B) 
by issuing a response (RES) which encapsulates the corresponding private key (X), and the 
values of two or more of the system parameters (g n ) are the same. 

23. A cryptosystem for encrypting messages to be transmitted from a transmitting user 
(A) to a recipient user (B) and for decrypting received messages with the help of a trusted 
third-party (TTP), the system making use of at least two private keys for each user, one 
private key (X Bl ) being held by the user and the other private key (X Bl ) being held by the 
trusted third-party (TTP), each message (m) being encrypted by the transmitting user (A) in 
accordance with public user parameters (Pb u Pb 2 ) that incorporate the private keys 
(X Bl X B2 ) of an intended recipient user (B) so that said recipient user (B) can only decrypt 
the message after a challenge (CHA) to the trusted third party (TTP) and a response (RES) 
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from the trusted third party (TTP) in which the said other private key (Xb 2 ) is encapsulated. 

24. A signature system for authenticating a message as originating from a user (A) by 
the user (A) encrypting the message (m) using one or more user encryption parameters (ki, 
k 2 ) selected by the user (A), and using said user encryption parameters (k b k 2 ) to generate 
encapsulated signed messages (s,, s 2 ) which are transmitted with the encrypted message (r) 
to a user (B) to allow authentication of the encrypted message (r) by the user (B) 
successfully decrypting it, the encapsulated signed messages (si, s 2 ) each incorporating a 
private key, one private key (X Al ) being held by the user (A) and the other private key 
(X Al ) being held by a trusted third-party (TTP) and only being released by the trusted 
third-party (TTP 1 ) in an encapsulated form (RES) when it receives a challenge (CHA) from 
the user (A). 
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